JavaScript模块化编程小结

1 引子

软件的生命周期跟人的生命周期类似，开发测试阶段只是其中很短的一部分（怀胎十月），而后期的运营维护阶段占据了整个生命周期的绝大部分（人的生长发育到最后down掉的几十年）。

一个比较直观的数据，需求分析和设计占1/5,开发测试占1/5,运营维护占3/5（这个占比可能会比这个大得多，比如一个几个月搞定的项目，可能会使用几年甚至几十年）。

因此，一切工程化手段都希望能够提升软件的可维护性，让运维周期更长，从而降低成本。

模块化概念最先出现在工程设计领域，比较常见的例子就是电脑的各个组成元件，手机的各个元件；在模块化的设计和生产之后，各大厂商可以很方便的进行组装，只需要相应的组件规格匹配就行。

这里就需要一个共同认可的规格文档，说明相应的规范参数，比如CPU的引脚，形状尺寸；内存的金手指数，卡槽位置等。

引申到软件设计上来，模块化的对外规范就是与其他模块的交互入口，可以是接口、信号、事件等传递数据的方式。至于内部使用什么样的逻辑来实现，对外部模块使用者来说其实并不太关注。

前面大致已经讲到了，模块是一个比较通用的概念，就是一个独立的功能体，与其相似的名词有插件，组件；

这个问题基本上已经回答了，简单列一下：

还是先回到软件生命周期，看看整个运维过程中可能出现的问题。

针对上面的这些问题，我们能做什么？

功能抽象
在生产一个功能的时候，尽可能的将不变的内容和可变的内容分离，让可变的内容可配置，这样固定的部分就可以被最大限度的复用，解决了不断复制一大片代码，修改其中一点作为新用的问题。
学习的代码
新代码的写入，应该是与现有的代码环境相适应，不管遗产代码质量怎样，都会被作为学习的对象；进一步说，不管你写的这片代码质量怎样，将来都可能被学习甚至是被复制；所以，好好写现在的代码，别误导新同学。
大胆开发，细心测试
如果现有的代码已经难以被复用了，不得不复制一份的时候，在复制的同时，输出一份可复用的代码，让复制止于此，让后面的同学可以愉快地复用现有代码。
人人为我，我为人人；功在当下，利在千秋
跳出恶性循环，进入良性迭代，我们的工作虽然只是多增加一只蝴蝶，却能让蝴蝶效应来的更猛烈。